簡介

在 Day18 淬鍊之章-使用 Lambda 呼叫 Glue Workflow 中，我們成功完成了整個自動化資料處理流程：

S3 → EventBridge → Lambda → Glue Workflow

這樣的架構能在每次有檔案上傳至 S3 時，自動觸發 Glue Workflow 進行 ETL，讓資料能即時地進入 Data Lakehouse，但此流程設計比較適合單檔上傳的 Event Trigger ETL。

在實務上，我們常會遇到這樣的場景：

• 一天的資料包含多個 dataset，例如：
  • animes.csv
  • ratings.csv
• 且需要將兩個檔案都上傳完成後，才能啟動此 ETL Pipeline。

如果仍維持原本的事件觸發機制，每上傳一個檔案都會呼叫一次 Lambda，就可能導致 Workflow 被重複啟動，甚至造成資料重複寫入或 Iceberg 衝突。

本篇讓我們一起來思考一下「多檔案上傳完成後才啟動 Glue Workflow」的解法。

問題分析

以下是原本的設計流程圖：

每個檔案上傳被偵測到後，都會各自觸發一次 Lambda → Glue Workflow 被啟動多次。

這樣會造成：

• 同一批資料被重複處理
• Glue Job 同時寫入同一張表
• 成本與執行時間上升

🧩 解題方式

為了解決多檔案上傳的問題，以下我們一起來看三個解決方案，各個方案都可以解決問題，但都有不同的優缺點需要做考量。

🧩 解法 1：使用 DynamoDB 管理上傳狀態

🔹 設計理念

透過 DynamoDB 追蹤每日上傳狀態，Lambda 只在「所有必要檔案都齊全」時才啟動 Glue Workflow。

🔹 流程圖

🔹 DynamoDB Table 結構

🔹 DynamoDB Table Schema

• date：從檔名解析出的日期（例如 20251003 → 2025-10-03）
• animes / ratings：布林值，代表該 dataset 是否已上傳完成
• workflow_started：是否已經啟動 Glue Workflow

🔹 解法一優缺點分析

✅ 優點

1. 即時性高： 每次上傳事件都能即時更新狀態，當所有檔案齊全時立刻啟動 Glue Workflow。
2. 成本極低： DynamoDB 採用 On-Demand 模式時，僅按請求次數計費，對每日少量檔案的情境幾乎可忽略不計。
3. 支援補傳歷史資料： 若上傳過去日期的檔案，系統會根據檔名自動比對日期並啟動對應的 Workflow。
4. 架構清晰、維護簡單： Lambda + DynamoDB 的組合邏輯簡單、模組化，能快速除錯與擴充。
5. 防止重複觸發： workflow_started 欄位可避免同一天的 Workflow 被重複執行。

⚠️ 缺點

1. 需額外維護狀態表： DynamoDB 雖然輕量，但仍需建立、授權與監控（特別是在多環境部署時）。
2. 檔案數量變多時需調整設計： 若每日需等待的檔案不只兩個，需擴充欄位或改為以「檔案清單」形式紀錄。
3. Lambda 執行邏輯稍複雜： 相較於單純事件觸發，需要額外的檔名解析與 DynamoDB 操作邏輯。
4. 狀態同步延遲的邊際情況： 若同時間多個檔案幾乎同時上傳，Lambda 並發更新 DynamoDB 可能需考慮「強一致性讀取」以避免 race condition。

🧩 解法2：使用 SQS 累積事件，集中批次觸發

🔹 設計理念

讓 S3 的上傳事件先送進 SQS Queue，由另一支 Lambda 每隔幾分鐘（或依 Queue 長度）批次處理，確認所有必要檔案上傳後再啟動 Glue Workflow。

🔹 流程圖

🔹 解法2 優缺點分析

✅ 優點

1. 事件緩衝能力強： SQS 可作為中間佇列，能有效吸收多檔案同時上傳的突發流量，避免 Lambda 被併發觸發過多次。
2. 可靠性高： 若 Lambda 處理失敗，訊息可留在 Queue 中或進入 Dead-letter Queue（DLQ），確保事件不會遺失。
3. 可批次處理： Lambda 可設定一次處理多筆訊息，統一檢查檔案齊全性後再啟動 Workflow。
4. 彈性調整觸發時機： 可根據 Queue 長度或累積時間，自行控制觸發頻率與批次大小。
5. 可整合更複雜邏輯： 適合高頻率上傳或跨多資料集的場景，例如需要等多個系統上傳後才執行的 ETL。

⚠️ 缺點

1. 架構相對複雜： 需要建立 SQS、設定 EventBridge 規則、Lambda Consumer 等額外元件。
2. 運維成本提升： 需監控 Queue 累積量與處理失敗的 DLQ 訊息，確保流程不堵塞。
3. 非完全即時： 雖然能快速反應，但仍需等待 Queue 累積到一定數量或時間才觸發批次。
4. 需額外控制重複事件： 若同一檔案事件被重送，可能導致 Lambda 重複處理，需要加上去重邏輯。
5. 成本與效能需權衡： 當上傳頻率極高時，SQS 請求與 Lambda 執行成本會隨之上升。

🧩 解法3：以 EventBridge Schedule 定時執行檢查

🔹 設計理念

使用 EventBridge Scheduler（例如每 10 分鐘執行一次 Lambda）來掃描 S3 Bucket，當發現該日期的所有必要檔案都存在時，再啟動 Workflow。

🔹 流程圖

🔹 解法3 優缺點分析

✅ 優點

1. 避免重複觸發： 不依賴 S3 事件，而是以排程方式定時檢查，因此無論同時上傳多少檔案，都只會啟動一次 Workflow。
2. 邏輯簡單、維護容易： 不需要使用 DynamoDB 或 SQS，只需一支 Lambda 週期性掃描 S3 即可判斷檔案齊全性。
3. 適合批次任務： 特別適合每日定時上傳資料的場景（例如每日 00:10 統一處理）。
4. 可整合排程監控： 可透過 EventBridge Scheduler 與 CloudWatch 進行統一監控與重試設定。
5. 穩定性高： 因為觸發頻率固定、流程單一，發生異常的機率相對較低。

⚠️ 缺點

1. 非即時處理： 由於是定時排程，會有固定延遲（例如每 10 分鐘檢查一次），不適合需要即時觸發 ETL 的情境。
2. 需撰寫檔案檢查邏輯： Lambda 需自行撰寫比對機制，確認所有必要檔案是否存在。
3. 排程時間需謹慎設定： 若上傳時間不穩定，可能導致該輪檢查時資料尚未齊全而錯過執行。
4. 高頻排程可能增加成本： 若設定過短的排程間隔（例如每分鐘），Lambda 執行次數將大幅增加。
5. 延遲與效能需權衡： 須在「即時性」與「成本控制」之間取得平衡。

三個方案的比較

結論與建議

在本篇中，我們探討了三種「多檔案觸發控制」的解決方案：

• DynamoDB 狀態表： 即時精準、成本低。
• SQS 批次處理： 適合高頻資料的環境。
• EventBridge 定時檢查： 簡單穩定，但延遲較高。

對於本系列的 Anime Lakehouse 專案 而言，每天只需處理固定的兩個檔案 (animes, ratings)，且可以跟使用者約定一個定期的上傳時間 (例如每天中午 12:00 做檔案上傳)，因此採用 EventBridge 定時檢查 是最理想的選擇。

下篇預告

本篇我們設計好流程後，下篇我們將進入 「Day21 淬鍊之章-多檔案上傳 ETL 流程-實作篇1」實際來建立這個 ETL Pipeline。

參考資料

[1] AWS Glue Workflow 官方文件
[2] Using AWS Lambda with Amazon S3
[3] DynamoDB Pricing
[4] Amazon EventBridge Scheduler
[5] Amazon Simple Queue Service